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Status Of This Memo 

This document is an Internet-Draft. internet-Drafts are working 
documents of the Internet Engineering Task Force (IETF), its areas, and 
its working groups. Note that other groups may also distribute working 
documents as Internet-Drafts. 

Internet-Drafts are draft documents valid for a maximum of six months 
and may be updated, replaced, or obsoleted by other documents at any 
time. It is inappropriate to use Internet-Drafts as reference material 
or to cite them other than as ~ work in progress. 11 

To learn the current status of any Internet-Draft, please check the 
^ lid-abstracts. txt r 1 listing contained in the internet-Drafts Shadow 
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East coast), or 
ftp.isi.edu (us West Coast). 

Distribution of this memo is unlimited. 



This* document describes a new feature for L2TP: it allows for a change 
of LACs during the lifetime of a PPP session without the latency of 
re-creating a new PPP session where possible. This feature is 
specially useful for wireless data services where the foreign wireless 
service provider (wsp) may be different than the user's home service 
provider and where a user f s mobility may result in a change of LAC 
during an on-going PPP session. This proposal presents 3 different 
methods of supporting this feature. The simplest method requires only 
minor changes to both LACs and lnss. However, it may give a larger 
handover latency. The other two methods have shorter handover 
latency and allow us to extend the L2TP session by an additional hop. 
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1. introduction 



Serving PPP 
IWF ~ Server 



MN < — > | | < > | | < > R ( internet) 



MN: Mobile Node 
R: Router 

IWF: interworking Function 



Fig 1 Typical wide area wireless access network architecture 



Fig 1 shows the architecture of a typical wide area wireless 
access network like CDMA, GSM, or TDMA. Current wireless standards 
allow mobile nodes (MN) to dial up a PPP server to access the 
internet. A link level tunnel is created between the serving 
IWF and the PPP server. If the mobile node moves to another 
serving iwf, link-layer messages are exchanged so that the tunnel 
between the old serving IWF and the PPP server is torn down and a 
new one set up between a. new serving IWF and the PPP server. 
If the mobile node moves further such that it has to change the 
PPP server, then current wireless standards force a termination of 
the PPP session. A new PPP session has to be negotiated between 
the mobile node and the new PPP server, in addition, current 
wireless standards do not provide virtual private networking 
services to mobile nodes. 

in current wireless architectures, the PPP server authenticates 
mobile nodes using the negotiated PPP authentication protocol e.g. 
CHAP, since it is not aware of mobile node handovers in the 
wireless network, it does not perform any authentication when a mobile 
node changes its serving IWF. 

in this document, we propose a mobile feature to the current IETF 
L2TP protocol to provide wide area mobility to nodes without having to 
renegotiate the PPP session during a handover. According to this 
proposal, mobile nodes need only implement the TCP/IP/PPP stack with 
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There are three methods to provide this mobile feature, namely 
(a) Simple AVP Approach (SAA) , (b) independent Tunnel Approach 
(ITA) , and (c) Concatenated Tunnel Approach (CTA) . Both the SAA and 
ITA require changes to both LAC and LNS software but the CTA only 
requires changes to the lac We list the advantages and disadvantages 
of these 3 different approaches in later sections, we prefer CTA 
because it provides end-to-end flow control for the 2-hop PPP 
session and it requires less CPU processing compared to ITA. 

This proposal is independent of the wireless access technologies. It 
provides hooks to carry mobile node security credentials between 
network access servers in a technology independent manner. It also 
makes no assumptions about the methods by which wireless terminals 
are identified or about the encryption and authentication methods 
used by the wireless networks. 

1.1 Limitations of L2TP for wireless services 

The current l2tp draft [1] does not allow for a transfer of Network 
Access server (NAS) during an existing PPP session. In a cellular 
environment, a change of NAS may occur during the lifetime of 
a PPP session. A user may start a PPP session and move into another 
service provider's coverage area which has a different NAS. 
The current L2TP draft forces the user to drop the currrent PPP 
session and renegotiate a new session, instead of terminating the 
existing PPP session and starting a new one which takes time and can 
be expensive in high capacity, micro-cellular wireless networks, one 
solution is to let the old NAS (LAC) transfer the PPP session to the 
new NAS (LAC). 

The current L2TP draft also does not allow mobile data users visiting 
a foreign wireless ISP to use the wireless ISP for virtual 
private networking services from an area where their home (wireless) 
ISP is not in operation. 



2.0 Overview of Mobile PPP 



There are three methods for providing the mobile feature. These 
methods differ in terms of their implementation complexity. The three 
methods are (i) simple AVP Approach (saa), (ii) independent Tunnel 
Approach (ITA), and (iii) Concatenated Tunnel Approach (CTA). 

2.1 Simple AVP Approach (SAA) 

with the Simple AVP approach, both the existing LAC and LNS need to be 
enhanced to process the User AVP, a newly defined AVP. 



Old ! Tunnel=2 

lac I 

callid-5 



LNS 



/ - 

/ Tunnel =3, callid=l 
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| New LAC | 
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New LAC LNS Old LAC 

Link 

Msg 1 SCCRQ 

> > 

SCCRP (with Mobile AVP) 

< 

SCCCN 

> 

ICRQ (with user avp) 
-> 

CDN 

> 

ICRP (with ACCM AVP, Proxy Auth AVP) 

< 

ICCN 

> 



Fig 2 Simple AVP Approach 



in Fig 2, we assume that the link layer message contains some subscriber 

information. Such information allows the new LAC, via the help of 

its local AAA server, to determine which LNS the new LAC should talk to. 

we assume that when a tunnel is set up between a LAC and a LNS, the 

LNS will respond with a Mobile AVP in its SCCRP message if it does support 

the mobility feature, in addition, the LNS will interpret any ICRQ. 

with- an attached User AVP as a possible signal of an handover for an 

existing PPP call, using the information provided in the User AVP, LNS 

can use its local AAA server and its connection table to determine the 

identity of the old LAC which the subscriber previously communicates 

with . 

if the LNS cannot accept the call handover, the LNS will send a CDN 
message to the new lac. If the LNS can accept the handover, the LNS 
will send a call Disconnect Notify (CDN) message to the old LAC. Next, 
the LNS replies with an ICRP message to the new LAC as stated in [1]. 
To support the handover feature, the ACCM AVP, and possibly the Proxy 
Authentication avp need to be included in the ICRP message. We 
assume that the sequence numbers will be re-initialized at the LNS 
after the handover. 

Note that we assume that the LAC does not initiate the teardown of 

L2TP session (unless a relatively long inactivity timer times out). 

Thus, there is no issue of LNS receiving a CDN message from the old 

LAC due to the handover before receiving the ICRQ message from the new LAC. 

The advantage of SAA is : 
(a) it is very simple. 

The disadvantages of SAA are: 

(a) Both the LAC and LNS software need to be updated to recognise 
the newly defined User avp message. 

(b) The handover latency may be long since the LAC may be located 
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within the WSP intranet while the LNS is located within the 
ISP or corporate network far away. 

(c) Roaming service may be limited to a smaller geographical area 
because the LACs within the WSP intranets and the LNSs within a 
corporate network do not trust one another unless there is a direct 
agreement between different WSPs and the corporate network. 

However, there may be cases where this approach is not secure or feasible. For 
such cases, we may need to extend the PPP session to a 2-hop session. 
A new entity called the Anchor LAC is introduced for the 2-hop 
session. 

2.2 independent Tunnel Approach (ITA) 

In the Independent Tunnel Approach, there are two L2TP data sessions 
per PPP call: one between the Serving LAC and the Anchor LAC; 
one between the Anchor LAC and LNS. To the Serving lac, the Anchor 
LAC looks like the LNS. To the LNS, the Anchor lac looks like the 
lac. The flow control procedure for the two data sessions is 
independent of one another. The Anchor LAC needs to provide a mapping 
table to map the tunnel and call identities of one data session to 
those of the related data session that belong to the same PPP call. 
Thus, the Anchor LAC has to maintain 2N data sessions for N PPP calls 
in ITA. 



I Anchor 

I LAC 



Tunnel=l | LNS | 
1 | 

callid=3 



Tunnel=3, callid=l 
| Serving LAC | 



Chuah expires June 1st, 1999 [Page 4] 

internet Draft Mobile PPP Nov 18th, 1999 

S-LAC: Serving LAC A-LAC: Anchor LAC 

client s-lac a- lac lns 

Link Layer 

Msgl SCCRQ 
> > 

sccrp (with Mobile avp) 
< 

SCCCN 
— > 

ICRQ (with User AVP) 
> 

ICRP (with ACCM AVP, Proxy Auth avp) 

< 

ICCN Auth_Req (Optional) 

> > 

ACK 
< 

Link Layer 
Msg2 
< 
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One hop to 2-hop Handover Scenario 
Fig 3 independent Tunnel Approach 

in Fig 3, we assume that the mobile subscriber first establishes 
a ppp call between the Anchor LAC and the LNS (tunnel id=l, callid=3). 
Then, the mobile subscriber roams to the coverage area of another new 
LAC (referred to as the Serving LAC). From the link-layer handoff 
message, the Serving LAC discovers that there is an existing PPP call. 
Thus, the serving LAC sends an ICRQ message which contains a User AVP. 
The Anchor LAC will first determine if this existing PPP call 
requests for an extended hop or for a change of LAC. Such a 
decision can be made with the help of the local AAA server and the 
information contained in the user AVP. Next, the Anchor LAC decides 
if this PPP call already has a 2-hop L2TP tunnel, if the Anchor lac 
determines that this existing PPP call needs an extended hop, it 
will create an entry in its mapping table (MT) so that the L2TP 
headers of all packets with (tunneTid=l,callid=3) from the incoming 
interface can be swapped with an L2TP header with (tunnel id=3, cal lid=l) 
at the outgoing interface. If a user-level re-authentication is 
desired, the Anchor LAC can send an Authentication Request message 
(an optional newly defined L2TP control message) to the LNS. 



LNS | 
I 



| Serving | Tunnel=3 I Anchor Tunnel=l 
| LACl | 1 LAC 

callid=l callid-3 

/ 

/ 

/ Tunnel=2, callid=5 



I New 

I Serving LAC2 
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Client S-LAC2 A- LAC LACl LNS 

Link Layer 

Msgl SCCRQ 
> > 

SCCRP (Mobile AVP) 
< ■ 

SCCCN 
> 

ICRQ (with user avp) 

. > cdn 

> 

ICRP 

< 

ICCN Auth_Req (Optional) 

> > 

ACK 

< 

Link Layer 
Msg2 

< 

2-hop to 2-hop Handover Scenario 
Fig 4 independent Tunnel Approach 
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in Fig 4, we show a 2-hop to 2-hop handover scenario. When the Anchor 
LAC receives the ICRQ with an attached user AVP, and finds an entry in 
the mapping table, it concludes that this is a 2-hop to 2-hop handover 
scenario. Therefore, the Anchor LAC sends a CDN message to the old lac, 
and updates the mapping table with the new 

tunnel and call identities carried within the ICRQ message. Again, 
if a user-level re-authentication is desired, the Anchor lac can 
send an Authentication Request message to the LNS to trigger such 
a reaction. 

The advantages of ITA are: 

(a) the handover latency is reduced due to a shorter hop distance 
between the Serving LAC and the Anchor LAC. The hop between the 
Anchor LAC and the LNS remains unchanged. 

(b) Roaming service can be more flexible. As long as there is an 
agreement between the home WSP and the corporate network, and between 
the home WSP. and other WSPs, the subscribers can roam to more 
places without having to terminate the ppp session. 

The disadvantages of ITA are 

(a) more complex than the Simple AVP approach 

(b) the Anchor LAC needs to maintain 2N flow-controlled data sessions 
for N ppp calls. 

2.3 concatenated Tunnel Approach (CTA) 

In the Concatenated Tunnel Approach, there is only one L2TP 
session per call but this L2TP session spans two hops: one between 
the Serving LAC and the Anchor LAC; one between the Anchor LAC and LNS. 
This approach requires more software enhancements to the Anchor 
lac However, the advantage is that it has end-to-end flow control 
and less CPU processing than the ITA. 
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Anchor | Tunnel =1 

LAC I 

callid=3 



LNS 



Tunnel=3 , callid=l 
[Serving LAC | 



Client S-LAC A-LAC LNS 

Link Layer 

Msgl SCCRQ 
> > 

SCCRP (with Mobile AVP) 

< :- 

SCCCN 
> 

ICRQ (with User AVP) 
> 

ICRP (with seq No, ACCM, Proxy Auth avps) 

< '■ 

ICCN Auth_Req (Optional) 
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> > 

ACK 

< 

Link Layer 
Msg2 

< 

One hop to 2-hop Handover Scenario 
Fig 5 independent Tunnel Approach 



The main differences between CTA and ITA are: 

(i) For cta, there is only one flow control procedure for the 2 hop. 
Thus, he Anchor LAC needs to send a Sequence Number AVP (which contains 
information on the latest Nr,Ns used before the handover) to 

the Serving LAC so that the Serving LAC knows what sequence numbers 
to start with. 

(ii) For CTA, the Anchor LAC merely observes and updates the latest 
(Nr, ns) information within the data packets traversing in either 
direction. It does not have to perform flow control actions on 

two data sessions as in the ITA. 

The advantages of CTA are: 

(a) we have an end/end flow control for the PPP call 

(b) the handover latency is reduced because of a shorter path between 
the Serving LAC and the Anchor LAC. 

(c) Roaming service can be more flexible. As long as there is an 
agreement between the home WSP and the corporate 

network, and between the home WSP and other WSPs, the subscribers 
can roam to more places without service interruptions. 

(d) it requires less CPU processing than ITA. 

The disadvantages of CTA are: 

(a) more complex than the Simple AVP and ITA approaches. 
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3 Service Model issues 

3.1 Authentication 

As in [1], the authentication of the user occurs in four phases; the 
first at the visiting WSP, the second at the Home WSP, and the third 
and optionally the fourth at the LNS. 

3 . 2 Accounting 

it is a requirement that the Serving LAC, the Anchor LAC and the 
LNS be capable of providing accounting data and hence all three 
parties may count packets, octets and connection start and stop 
times. 

Accounting statistics collected by the Serving LAC and the Anchor 

LAC are sent to their AAA Servers. The accounting Server 

in the Foreign Network may forward accounting statistics 

to the Home Accounting Server periodically (weekly, monthly). 
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4.0 Control Message Processing 
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For the 3-hop scenario, we assume that any party, namely the Serving 
lac, the Anchor LAC or the lns can terminate the session by sending a Cal 
Disconnect Notify. If the Anchor LAC desires to terminate the session, 
then the Anchor LAC has to send a Call Disconnect Notify message to 
both the Serving LAC and the LNS . 

Note that in the three hop scenario, the Hello messages for the 
control connections between the Serving/Anchor LACs and between 
the Anchor LAC and LNS are done independently of one another for both 
the independent and Concatenated Tunnel approaches. The Anchor LAC is 
expected to relay all the set-Link-Info, and wan-Error-Notify messages. 



4.1 Newly Defined Control Message and avps. 

To support the tunnel extension and call transfer features, we define 
one optional control message, namely the Auth_Request message. This 
message allows the LAC to inform the LNS to trigger a PPP level 
re-authentication with the PPP client during handover. 

in addition, we define four new AVPs: (i) Mobile AVP, (ii) User AVP, 
(iii) Sequence Number AVP, (iv) A-LAC window AVP. The Sequence No, 
a-lac Window are used only in the CTA. we refer the readers to 
Appendix 1 for more information on when these 3 AVPs are used in the CTA. 

4.1.1 Authentication Request (Auth_REQ) 

Authentication Request message is sent from a LAC to an LNS to trigger 
the LNS from initiating a PPP reauthenti cation with an existing 
user. 

Message Format for Authentication Request 

I L2TP control message header | 
++++++++++++++++++++++++++++++++++++++ 
| Authentication Request I 
++++++++++++++++++++++++++++++++++++++ 
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4.1.2 Newly Defined AVPs 

The new AVP is encoded as Vendor ID 1751 which reflects Lucent 
Systems, the initial developer of this specification, and it 
should be changed to 0 and an official Attribute value chosen if 
this specification advances on a standards track). 



0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+-+-+-+-+-+-+~+-+-+ 
|M|H|0|0|0|0| Overall Length | vendor ID | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Attribute | value... I 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| [until Overall Length is reached]... I 

+ - + - + ~ + - + - + - + - + - + - + -+- + -+- + -+-+-4--+-+-+- + - + - + -+-+-+-4-- + - + -+-+-+- + 

The first six bits are a bit mask, describing the general 
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attributes of the AVP. 



The three newly defined AVPs are: 
Attr M Len Attribute Name 

40 18 Mobile AVP 

41 1 16+ User AVP 

42 1 10 Sequence Number AVP 

43 18 Receive Window Size AVP allowed by the Anchor LAC 

The existing Receive window Size AVP in [1] with Atribute vallue 10 
is used to communicate the receive window size allowed by the LNS. 

4.1.2.1 Mobile AVP 

This avp is used by the lns/a-lac to inform a lac that the lns/a-lac 
supports the mobility feature. 



Message Format for Mobile AVP 

0 1 2 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I 1| 1| 0| 01 Length | Lucent-vendor id | 

| 40 | Support Mobility | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 



4.1.2.2 user's AVP 

This avp is used to provide user's name and user's credentials. 
The user's credentials may include information like user's 
identity (IMSI), phone number. This AVP may be a hidden AVP 
(according to section 5.7 in the L2TP draft [1]). 



Message Format for User's AVP 

0 12 3 

.0123456789012 3 456789012345678901 

|1| 1| 0| 01 Length | Lucent-Vendor ID | 

+-+-+-+-+-+-+-+-+- ; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 41 | user-Service I 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— f -+-+-+-+-+-+-+-+-+-+ 
| ASCII Representation of 15 digit No | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Phone Number I 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 



user's avp 

- contains information about the user's name and user's 
credentials e.g. multihop virtual dial up service, user's 
identity (MIN), service provider's phone number, user level 
authentication information, etc 
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4.1.2.3 Sequence Number AVP 

This avp is used to convey (Nr, Ns) information to the new 
Serving LAC. This AVP is only used in the Concatenated Tunnel approach 
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and is attached to the ICRP message. 

Message Format for Sequence Number AVP 

0 1 2 3 

01234567890123456789012345678901 

|1|1|0|0| Length | Lucent-Vendor ID 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^ 

| 42 | Reserved 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^ 

| Nr | Ns 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Nr - next received sequence number to be expected. 
ns - next sending sequence number. 



4.1.2.3 A-LAC Window's AVP 

This AVP is used by the Anchor LAC to inform the new Serving LAC of 
the A- lac's payload window size. The original Receive Window AVP is 
used to convey LNS's window size. The format is exactly the same 
as the Receive window AVP stated in [1]. This AVP is only required 
for the Concatenated Tunnel approach and is attached to the 
ICRP message. 



5. security issues 

in our proposal, the Serving and Anchor LACs may belong to the same 
wsp or they may belong to different wsps. For the case where they 
belong to the same WSP, we do not introduce any new security threats. 
For the case where they belong to different WSPs, we assume that 
if a corporate net trusts a particular WSP, say WSPl, and WSPl trusts 
another WSP, WSP2, then the corporate network trusts WSP2. 
IP security can be supported between Serving LAC and LNS for 
the triplet case using extended ideas described in the draft 
"Securing L2TP using IPSEC" [2]. 
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Appendix 1 using cta in a Handover Scenario 

Assume that the subscriber has a PPP call which spans two 

hops between the s-LACl, A-LAC and the LNS. Then, the subscriber moves 

to the coverage area of a new LAC, S-LAC2 . 

Message Flows for this handover scenario: 

S-LAC2 A-LAC S-LACl LNS 

Link Msgl ICRQ 
--> Orig ICRQ 

user's avp 



CDN 



Link Msg2 

<- 



ICRP 

Orig ICRP 
seq No AVP 
a-lac window avp 
LNS window avp 

ACCM AVP 



Link Msg3 

— > 



ICCN 
Orig ICCN 



Auth_Req (optional) 



ACK 



Orig ICRQ - means the ICRQ message as stated in 
Orig ICRP - means the ICRP message as stated in 
orig ICCN - means the ICRP message as stated in 



[1] 
[1] 
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Appendix 2 Transfer of Sequence Number During Handover 

Here, we describe how the sequence numbers are updated 
during a handover if CTA is used. 

A2.1 Handover from a 2-hop to a 3-hop configuration. 

Old LAC LNS 
Ss=13 SS=7 
Sr=6 sr=10 

The old LAC (which is now the A- LAC) will set Nr=6, Ns=13 in the 
sequence Number avp within the ICRP message. After the handover, 

New S-LAC A-LAC (Old LAC) LNS 
SS=13 SSAS=13 SSAL=7+ SS=7+ 

sr=6 SrAS=6 SrAL=10+ Sr=10+ 



A2.2 Handover from a 3-hop to a 2-hop configuration. 



Old S-LAC A- LAC LNS 

SS=13 SSAS=12 SSAL=6 SS=7 

Sr=5 SrAs=4 SrAL=9 Sr=10 

The Anchor LAC will set (Ss=SsAs, Sr=SsAL) and drop the 
4 tuple (SsAl, SrAL,SsAs,SrAs) as shown below: 

A- LAC (LAC) LNS 
Ss=12 SS=7+ 
Sr=6 Sr=10+ 



A2.3 Handover from a 3-hop to another 3-hop configuration. 

New S-LAC Old S-LAC A-LAC LNS 

SS=13 SSAS=12 SSAL=6 SS=7 

Sr=5 SrAs=4 SrAL=9 Sr=10 



The A-LAC sets Ns=SsAs=12, Nr= SsAl=6 in the Sequence Number AVP 
within the ICRP message which is sent to the new S-LAC. After the 
handover, we have 

New S-LAC A-LAC LNS 

Ss=12 SsAS=12 SSAL=6+ Ss=7+ 

Sr=6 SrAs=6 SrAL=9+ Sr=10+ 

Appendix 3 Multiple LNS Scenario 

For the case where a LAC may potentially communicate with more than 
one LNSs, the mobile feature will still work as long as the order 
at which any LAC tries a possible list of LNSs is the same. 
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